import {Meta} from '@storybook/addon-docs/blocks';

<Meta title="Guide/Page Architecture" />

# Page Architecture

These principles apply for OJS, OMP, and OPS version 3.5 and higher when building new pages or making significant changes to existing ones.

Since this is a recent change, we have a limited number of examples in our code base. At this point it's best to follow [Example Page](?path=/docs/pages-example--docs) and [New Submission Page](?path=/docs/pages-submissions--docs). There is more to come soon.

## Folder structure

All Page related files are located in the `lib/ui-library/src/pages` folder. Check out [ExamplePage](?path=/docs/pages-example--docs#folder-structure) for per-file breakdown.

## Page template included in Page component.

To [simplify](?path=/docs/guide-technical-roadmap--docs#vuejs--smarty---vuejs-35) the developer experience when creating Pages, we are moving from a combination of Smarty and Vue.js to using pure Vue.js components, which have templates as part of the component file.

## State management

For managing Page business logic we are leveraging [Pinia store](../?path=/docs/guide-pinia-store--docs). The main reason why we want to use Pinia stores instead of just managing state directly in the Page component, is that behind the scenes it's very extensible and plugin friendly. You can check out a more detailed break down in our [Technical Roadmap](?path=/docs/guide-technical-roadmap--docs#pinia-stores-35). General UI components still contain interaction logic directly in the component.

To understand how the Components should interact with the **Component Pinia Store**, which is our simple extension of the Pinia Store, check out the dedicated [page](http://localhost:6006/?path=/docs/guide-pinia-store--docs#component-pinia-store) for Pinia store.

### Where to place business logic?

- **Page**: Every Page will have its own [Component Pinia Store](?path=/docs/guide-pinia-store--docs#component-pinia-store), where most of the business logic is handled and for simpler Pages that should be good enough.
- **Complex Modals**: If Pages contain Modal(s) that contain substantial functionality, which is reasonably well separable from the rest of the Page, then it's a good indication that the Modal should have its own Component Store. A good example is `SubmissionSummaryModal.vue`.
- **Self-Contained Component aka Managers**: Good candidates in general are Components that can be used in multiple places, and their logic can be well separated from the rest of the page. Existing examples: [FileManager](../?path=/docs/managers-filemanager--docs), [ReviewerManager](../?path=/docs/managers-reviewermanager--docs), [ParticipantManager](../?path=/docs/managers-participantmanager--docs), [GalleyManager](../?path=/docs/managers-galleymanager--docs).

## Server side configuration

On initial page load, there is still an opportunity to pass JSON objects from PHP to Vue.js. It is best to express individual items as props, so they can be easily displayed in storybook and well documented.

This might include things like:

- Form structure configuration, as we do configure forms on the PHP side.
- Any configuration which needs to be passed just once on page load.

## Styling

For styling use TailwindCSS. For more details check out [styling guide](../?path=/docs/guide-style-introduction--docs).
